\chapter{$\pi$SOD-M: A Methodology for Building Reliable Service Based
Applications}
\label{chapter:methodology}


\epigraph{``\textit{There are two ways of constructing a software design: One way is to make it so
simple that there are obviously no deficiencies, and the other way is to make it
so complicated that there are no obvious deficiencies. The first method is far
more difficult.}''}{C.A.R. Hoare}
  

Software is moving towards models, methodologies, software process and
architectures that should be easily modeled and developed, accommodate changes
and integrate new functionality. Different requirements and non-functional
requirements (NFRs) may demand such a robust method to provide the necessary
support for the modeling and development software process. There exist several
proposed methodologies, methods and new approaches for software engineering,
with the objective of improving software development and modeling non-functional
requirements. There are still a number of problems to be solved in the
development of services-based applications, \textit{e.g.}, automatic
composition; NFRs specification and model; and specific development
methodologies for service-based applications. 

Based on this context, this chapter presents $\pi$SOD-M (\textit{Policy-based
Service Oriented Development Methodology}), a methodology for modeling and
developing reliable web service based applications. We propose
guidelines for building service compositions that include non-functional
requirements (NFRs). The methodology focuses on the development of
behavioral aspects of the software being developed. These behavioral aspects are
implemented by each application service, integrating those functional and
non-functional aspects required by the system.

This chapter is organized as follows. Section
\ref{sec:pisodm} discusses the concepts, general structure and motivations
to define a specific methodology for policy-based web service development.
We also introduce a motivational example for
illustrating the features of $\pi$SOD-M. Sections \ref{sec:pim-pisodm},
\ref{sec:psm-pisodm} and \ref{sec:models-tranformation} describe the development
models and transformations of our methodology, as well as how apply the
methodology concepts for building concrete applications, considering the
motivational example. Section \ref{sec:pisodm_conclusion} concludes the chapter.

\section{$\pi$SOD-M} 
\label{sec:pisodm}

$\pi$SOD-M is a MDA (Model Driven Architecture) based methodology, providing
a framework for building service compositions considering their non-functional
requirements. $\pi$SOD-M extends the SOD-M \cite{valeriaThesis} method by adding
new concepts for representing non-functional aspects. $\pi$SOD-M also proposes
the generation of a set of models at different abstraction levels, as well as
transformations between these models. Our approach extends the original
method with the notion of \textit{Policy}
\cite{Espinosa-OviedoVZC09,Espinosa-Oviedo2011a} for representing non-functional
aspects associated to service-based applications. 

$\pi$SOD-M's models represent both the cross-cutting aspects of the application
being modelled, as well as the constraints associated to services. The systems
cross-cutting concerns are aspects of a program which affect other concerns,
such as availability; recovery; and persistence aspects. While constraints are
restrictions that must be respected during the execution of the application,
for example the fact that a service requires an authentication for executing
system funcitons.

All development proposed in $\pi$SOD-M is based on MDA, and a
model driven development process needs both models at different
abstraction levels and transformations between them. The
transformations allow us to relate elements from an input source model to an
output target model (different from each other). At each level it is performed a
transformation between models to refine the specification of the system.


$\pi$SOD-M defines a service oriented approach providing a set of guidelines to
build service based information systems (SIS) and proposes to use services as
first-class objects for the whole system development process. $\pi$SOD-M
provides a conceptual structure to: (i) capture the system requirements and specification in
high-level abstraction models (computation independent models, CIMs); (ii)
obtain the PIMs from such models (specification documents). The
platform independent models (PIMs) are designed specifying the system details;
(iii) transform such models into platform specific models (PSMs) that bundles
the specification of the system with the details of the targeted platform; and
(iv) serialize such model into the working-code that implements the system.


As one of the main aims of MDA is to separate design of architecture and
technologies, the $\pi$SOD-M's models describe the system behaviour and its
restriction, considering any definition of standard architecture, because the
devising of the system's architecture is outside the scope of our work.We
consider that all applications to be modeled are services. $\pi$SOD-M extends
the SOD-M models to include NFRs modelling aspects. The SOD-M models that are
being extended are: \textit{use case model, extended use case model, service
process model} and \textit{service composition model}.


The SOD-M \textit{use case} and \textit{extended use case} models were extended
to a single model named \textit{$\pi$-UseCase}. The \textit{$\pi$-UseCase} model
describes services requirements, constraints and quality requirements. The original models
(\textit{use case} and  \textit{extended use case} models) do not define
concepts to design non-functional restrictions, which are considered in the
\textit{$\pi$-UseCase} model. The \textit{service process} model was extended to
\textit{$\pi$-ServiceProcess} model. In this model we propose the definition of service contracts.
\textit{$\pi$-ServiceProcess} model groups the constraints described in
\textit{$\pi$-UseCase} model into contracts that are associated with services. The
\textit{service composition} model was extended to
\textit{$\pi$-ServiceComposition} model. The contracts specified in the \textit{$\pi$-ServiceProcess} model are
refined into policies in the \textit{$\pi$-ServiceComposition} model.
\textit{Policy} groups contracts with the same non-functional requirements. For
example, security restrictions, such as contracts for authentication, privacy
data access or transactions are grouped into a security policy.

The services restrictions are being refined into each level of modeling. In the
\textit{$\pi$-UseCase} model, use cases restrictions are designed as
constraints. In the \textit{$\pi$-ServiceProcess}, the constraints are grouped
in service contracts, and use cases are refined to services or functions. Then,
contracts are grouped into policies.


 The methodology proposes the \textit{$\pi$-PEWS} model as platform specific
 model. \textit{$\pi$-PEWS} model is generated from the
 \textit{$\pi$-ServiceComposition} model, and it is a representation of
 \textit{$\pi$-PEWS} specification \cite{BaCAM05,Placido2010LTPD}. The original
 version of SOD-M does not provide this platform model. From
 a \textit{$\pi-$PEWS} model it is possible to generate a service composition
 specification code. Figure \ref{fig:sodmExtensions} presents the SOD-M models in the context of MDA
 architecture, and which models are extended by our approach.

====>>>>> PAREI AQUI <<<<<=========


\begin{figure}[ht]
\centering
\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/ArquiteturaPiSOD-M}
\caption{SOD-M Extension Models.}
\label{fig:sodmExtensions}
\end{figure}

  $\pi$SOD-M also defines model-to-model transformation rules, starting from
  the\textit{$\pi$-UseCase} model to \textit{$\pi-$ServiceComposition} model;
  and, using model-to-text transformations, generate the corresponding
  implementation code in \textit{$\pi-$PEWS} model. Non-functional requirements
  are modelled from high-level platform independent models, and then the
  specific platform code is generated.


\begin{figure} [ht!]
\centering
\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/PiSOD-MProcess}
\caption{$\pi$SOD-M Development Process and Models.}
\label{fig:developmentProcess}
\end{figure}


$\pi$SOD-M uses the concept of MDA viewpoint, used as a technique of
abstraction to focus on a particular aspect of the issue or proposed system.
MDA defines, specifically, three viewpoints:

\begin{itemize}
  \item \textbf{Computation Independent Viewpoint:} This level (as presented in
  figure \ref{fig:developmentProcess}) is focused on the system environment and
  the business and requirements specification, where the  structure and system processing details are still unknown or
  undetermined. In $\pi$SOD-M, this level is represented as a list of business
  services from a requirements and business specification.
  \item \textbf{Platform Independent Viewpoint:} This level is focused on system
  functionality, but hiding the details of a particular platform, showing that
  part of the system not changes from one platform to another. In $\pi$SOD-M,
  this level is modelled the system use case, service
  process and service composition models.
  \item \textbf{Platform Specific Viewpoint:} This level is focused on system
  functionality, but not hiding the details of a particular platform, combining
  the platform independent view with the specific aspects of the platform to
  implement the system.  In $\pi$SOD-M, the result of this level is the
  $\pi$PEWS specification \cite{Placido2010LTPD} represented as a platform
  specific model.
\end{itemize}


 CIM models aim to represent the business view, while PIM and PSM models aim to
 represent the information system view, and detail the information system to be
 implemented to fulfill the requirements of a business environment.

 Figure \ref{fig:developmentProcess} presents $\pi$SOD-M development process,
 which defines a service oriented approach providing the guideline to build
 services' based information systems (SIS), that was the result of the SOD-M
 extension described in figure \ref{fig:sodmExtensions}. Notice that it is
 possible to have different platform models in PSM level (figure
 \ref{fig:sodmExtensions}), such as BPEL or WSDL model. However,
 $\pi$SOD-M defines the \textit{$\pi$-PEWS} model as platform specific model.

Next section presents the concepts that lead to modeling applications in
$\pi$SOD-M. These concepts form the basis of the methodology for modeling the
reliable service-based applications.

\subsection{Methodology Concepts}
\label{sec:concepts}

$\pi$SOD-M proposes a new approach for defining non-functional
aspects in service-oriented development. The methodology relies on a
set of concepts (represented as a meta-model) that are necessary for modeling
reliable applications. These concepts are structured in three views:
\textit{Business, System} and \textit{Policy view}. Each concept has a
representation in each model proposed by $\pi$SOD-M. The methodology views are:

\begin{itemize}
  \item \textbf{Business view:} focuses on the business features
  that are the basis of an information system.

  \item \textbf{System View:} focuses on the main features and
  processes for the information system development.

	\item \textbf{Policy View:} focuses on non-functional requirements and
	business constraints of the information system.
\end{itemize}

The concepts that correspond to the \textit{Policy View} describe the NFRs and
constraints related to the system functionalities. Those that
correspond to the \textit{Business View} describe business elements. Those that
correspond to \textit{System View} are used to describe the functionality and
processing system. Those concepts which correspond to both perspectives
(\textit{Business and System View}) can be analyzed from both perspectives.
Figure \ref{fig:pisodm-concepts} shows the set of concepts proposed by
$\pi$SOD-M, which are organized in defined views.

$\pi$SOD-M main goal is to model non-functional requirements
(\textit{Policy View}) considering the
models proposed in SOD-M methodology. The SOD-M concepts do not provide this
level of modeling. Thus, our proposal add non-functional
aspects concepts for modeling reliable software from early stages
of service application specification. The $\pi$SOD-M concepts are:

\begin{itemize}
  \item \texttt{Business process -} Represents a set of logically related tasks that
are carried out to achieve a given business result.
  \item \texttt{End consumer -} Represents an entity that needs and consumes a
  business services. End consumer are those who pay (either with money or using
  any other valuable object) to obtain a service that they use themselves.
  \item \texttt{Business service -} Represents a result of a business process
  (or part of it) providing value for an end consumer, created because the
  interaction end consumer/service provider permits fulfillment of an end
  consumer's specific need.
  \item \texttt{Business task -} Represents a business function performed by a
  business collaborator as a part of a business process.
  \item \texttt{Business collaborator -} Represents an entity that collaborates
  in the business processes of an organization, performing certain tasks needed
  to provide a business service.
  \item \texttt{Use case -} Represents a set of actions performed by the system
  to carry out part of a business service.
  \item \texttt{Composite use case -} Represents a set of actions performed by
  the system to carry out part of a business service, which can be broken down
  into different use cases, which may in turn be basic or composite.
  \item \texttt{Service composition process -} Represents a set of logically
  related activities necessary for carrying out a business service.
  \item \texttt{Service activity -} Represents a behaviour (set of individual
  actions) forming part of the execution flow of a business service.
  \item \texttt{Action -} Represents a fundamental behaviour unit that is part
  of a service activity and describes some transformation or processing in the
  system being modelled.
  \item \texttt{Non-Functional (NF) Attribute -} An attribute that describes
the quality or characteristics of a functional requirement. For example
\textit{confidentiality} and \textit{privacy} is an example for a non-functional
attribute for the functional requirement \textit{user registration}.
  \item \texttt{Non-Functional (NF) Requirement -} A group of semantically
correlated non-functional attributes (NFA). For example, \textit{security} is
an NF Requirement that comprises attributes such as \textit{confidentiality}
and \textit{integrity}.
  \item \texttt{Constraint -} A constraint prevents the system
  from achieving more than its goal. With the definition of constraints, the
  system  can be more robust, and unexpected problems can be solved before it
  happens. For example, in a banking system, the customer can only withdraw
  money if you have a positive balance in the account.
    \item \texttt{Constraint Type -} Represents the types of restrictions
  constraints expressed in the meta-model are business and data (*value) constraints. When
  modeling a system requirement the analyst can identify if there are restrictions on
  business, or data, or both.
  \item \texttt{Contract -} Is the formalization of obligations (requires) and
  benefits (ensures) of a function, service activity or component.
  The following questions can be used to define contracts: \textit{What does it
  expect? What does it guarantee?} Contract are crucial to software correctness
  that they should be part of the design process. An interface is a kind of contract.
  \item \texttt{Assertion -} Represents a predicate or a state of the
  application before it runs (its preconditions), or the state when it is
  finished running (post-conditions);
  \item \texttt{Exceptional Behaviour -} Are alternative execution paths if
  any condition or restriction is not respected. For example, if a User's password
  is not correct after three attempts, the User account is locked for security
  reasons.
  \item \texttt{Policy -} A policy is a set of rules applied to a particular
  scope. This scope can be defined as an action, an activity, a function or a
  workflow. A policy is a composition of contracts applied to a non-functional
  application requirement. For example, a security policy of a system constraint
  includes authentication, access, data privacy, and so on.
  \item \texttt{Requirement -} Represents a super type for functional and
  non-functional requirements. Thus, the use cases can be related to both types
  of requirements.
  \item \texttt{Rule -} Represents information about an event, condition, and
  action where the event part represents the moment in which a constraint can be
  evaluated according to a condition represented by the condition part and the
  action to be executed for reinforcing it represented by the action part.
  \item \texttt{Variable -} Represents a symbolic name given to some known
  information. A variable are related with a Policy. A Policy can have one or
  many variables. Each Variable has a name and a type.
\end{itemize}



\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/methodology/figs/PiSOD-M.pdf}
\caption{$\pi$SOD-M Concepts.}
\label{fig:pisodm-concepts}
\end{figure}



The concepts presented in figure \ref{fig:pisodm-concepts} represent the main
elements of the methodology used for system application modeling. The $\pi$SOD-M's
meta-model\footnote{\textit{Meta-model} is the construction of a collection of
``concepts'' (things, terms, etc.) within a certain domain. A model is an
abstraction of phenomena in the real world; a meta-model is yet another abstraction, highlighting properties of the model
itself. A model conforms to its meta-model in the way that a computer program
conforms to the grammar of the programming language in which it is written.}
elements are used in all methodology meta-models. These elements
describes the key concepts that must be modelled in a service-oriented
application. As the proposed approach is in the context of MDA, the $\pi$SOD-M
meta-model consists the set of concepts for modelling and development
applications that use our approach. These concepts represent the reliable
service-based system development, and are present in the modeling of each
application.

Notice that the three $\pi$SOD-M methodology views (\textit{Business, System}
and \textit{Policy}) are different to those levels proposed in MDA:
\textit{CIM, PIM} and \textit{PSM}. Each $\pi$SOD-M meta-model, at
different MDA levels, there will be elements from the $\pi$SOD-M concepts. For
example, in the \textit{$\pi$-UseCase} model (\textit{PIM} level) uses the {\sc
Use Case\footnote{We use {\sc capitals} for referring to meta-models' classes.}},
{\sc Constraint, Business Service, End Costumer} and {\sc NF Requirements}
concepts to represent what is being modeled. {\sc Business Service} and
{\sc End Costumer} are elements that model \textit{Business} concepts, while
{\sc Use Case} models \textit{System} concepts and, {\sc Constraint} and {\sc
NF Requirement} model \textit{Policy} concepts. The same is true for all other
$\pi$SOD-M models, \textit{$\pi$- ServiceProcess,
$\pi$-ServiceComposition} and \textit{$\pi$-PEWS}. The relationships
among these $\pi$SOD-M concepts are also presented in figure
\ref{fig:pisodm-concepts}, and especially the {\sc Policy} level for quality
requirements modeling.

\bigskip
\bigskip

Considering the set of concepts presented, each of them aims model
important parts of the application. The services-based systems represent
business relationships through {\sc Business Services},  in a more abstract
level. {\sc Business Services} make up different application services, in order
to perform a business relationship. Services are system features being
modeled by {\sc Use Cases}. {\sc Use Cases} are refined at each
development iteration, where s set of restrictions are
specified for each function or service. System restrictions are represented
through {\sc Constraints}, {\sc Contracts} or {\sc Policies}. {\sc Constraints}
are restrictions on {\sc  Use Cases}, while {\sc Contracts} are restrictions on
{\sc Actions}, or their specific functions, and {\sc Policy} is a restriction
on a group of services that can be represented as {\sc Service Activity} or a
{\sc Service Composite Process} . Thus, these terms specify particulars of the
application at different modeling levels.


Based on this, so that all the system features needed are specified, these
concepts relate to each other in order to describe each use case, function,
service or  application process. One {\sc Requirement}, whether functional or
non-functional, represents by one or more {\sc Use Cases}. For example, a
payment process can be modelled through the use cases that represent withdrawal
and deposit of money in transaction of customer accounts. A payment process also
requires the guarantee of a complete transaction and data security. Thus, some
use cases can compose a single requirement.

A {\sc Composite Use Case} represents a type of {\sc Use Case}. This type of
use case abstracts a more macro function, and may contain extra functions to be
performed so that the process is complete. For example, to publish a song in a
social network, you must choose which song you want to publish, authenticate, so
that the music you're listening is published. We consider this type of use case,
a use case compound.

Each {\sc Use Case} has many {\sc Constraints} (business or
value constraints). Business constraints represents restrictions expressed on
functions and how they may be implemented. Value constraints are restrictions on the
service interface, which detail the desired values  for input and output
data. Each constraint is associated with {\sc Non-Functional Attributes} (NFA).

A {\sc Contract} consists of a set of {\sc Constraints}. As a {\sc Contract}
represents a composition of assertions, each {\sc Constraint} are
refined into {\sc Assertion} that will compose one {\sc Contract}. For
example, a contract for the payment operation by credit card, the value should
not be less than 10 euros and the user should always receive a purchase
confirmation by email or by phone message. This set of restrictions will be
composed into a single contract for payment transactions. These constrains are
also associated with non-functional attributes, e.g., \textit{reliability,
transactions and privacy data}.

An {\sc Exceptional Behavior} represents a non excepted system behavior or
a contract violation. When this happens other function is called
or the application process is stopped. In $\pi$SOD-M, this entity represents the
contract violation. For example, if the bank does not authorize the payment, the
system or service offers alternative forms of payment such as a bank invoice or
purchase via PayPal.


Finally a {\sc Policy} groups similar {\sc Contracts}, \textit{e.g.}
contracts for the application safety, or contracts on the system performance are
grouped as policies. For example, payment and authentication contracts are
grouped into \textit{security} policy, as well as contracts that require a
time-out processing, are grouped into \textit{performance} policy. Each policy
is associated with a non-functional requirement, a set of {\sc Rules} and
{\sc Variables}. Each {\sc Non-Functional Requirement} is associated with
one or more {\sc Non-Functional Attributes}.


 All the proposed $\pi$SOD-M concepts and models for business modeling (CIM
 level), and for modeling the information system and policy at PIM and PSM
 levels are important for the development of reliable systems. The following next sections
will describe the example scenario for better explain the $\pi$SOD-M meta-model
and the methodology concepts.

The description of each methodology concept is important to identify the views
elements throughout the development. The concepts will be clearly highlighted in
the description of each $\pi$SOD-M meta-model. Thus, the purpose of this section
was to present an initial description of each concept, so that when used, be
seen in its proper modeling application.


\subsection{Case Study}
\label{sec:example}

To conduct the description of specific details of the methodology proposed in
this work, we use a case study that will drive this process. We will specify the
application of concepts and models in this case study so that each detail is
presented in order to facilitates the design of the proposed models, as well as
they should be used in a real development. We will try to cover all $\pi$SOD-M
features through clear examples, and while the application is being
developed, concepts, activities and models are explained.

Consider the following scenario: An organization
wants to provide the service-based application ``\textit{To
Publish Music}'' that monitors the music a person is listening
during some periods of time and sends the song title to this
person's Twitter or Facebook accounts. Thus, this social
network user will have their status synchronized in Twitter \footnote{Twitter is
an online social networking service and micro-blogging service that enables its
users to send and read text-based posts of up to 140 characters, known as
``\textit{tweets}''.} and Facebook\footnote{Facebook is a social networking
service and website. Users may join common-interest user groups, organized by
workplace, school or college, or other characteristics, and categorize their
friends into lists} (i.e., either the same title can be published in both
accounts or it is not updated) with the title of the music the user is listening
in Spotify\footnote{Spotify is a music streaming service offering digitally
restricted streaming of selected music from a range of major and independent
record labels. Spotify allows registered users to integrate their account with
existing Facebook and Twitter accounts.}. The user may also want
to download music, but for this, the user needs to process the purchase of music
they want to download. The user can pay via PayPal or credit card. All services
are available via Spotify and this application needs to interact with Spotify
users, so they can listen music, publish them on Facebook and Twitter, or
purchase music online. For developing this service-based application lets
consider the use case model illustrated in figure \ref{fig:example_usecase}.


\begin{figure}[ht!]
\centering
\includegraphics[width=.95\textwidth]{chapters/methodology/figs/runningExampleUCSingle.pdf}
\caption{Use Case Model ``\textit{To Publish Music}'' - Spotify Music Service.}
\label{fig:example_usecase}
\end{figure}

Figure \ref{fig:example_usecase} shows the use case model for the ``\textit{To
Publish Music}'' application. As long as the user listens the music, they can
publish the music information on social networks. For downloading music, it is
necessary to purchase the song the user wants. To publish songs, the user must
login and authenticate on the social networks services, and for that there are
constraints to be modelled and implemented. The same is true for purchasing
music, where some integrity and confidentiality of the credit card
data are required.


Figure \ref{fig:example_serviceprocess} shows the activity model for our
scenario. It starts by contacting the music service Spotify for retrieving the
user's musical status.  If the user wishes to download a particular song, she can
execute the download path to purchase (activities \textit{Buy Music} and
\textit{Download Music}). Finally the user can publish the music. The \textit{publish
music} can also be modelled into parallel flow for update different social
networks. Twitter and Facebook services can then be contacted in parallel for
updating the user's status with the corresponding song title.

\begin{figure}
\centering
\includegraphics[width=.95\textwidth]{chapters/methodology/figs/runningExampleSPSingle.pdf}
\caption{Service Process Model ``To Publish Music''}
\label{fig:example_serviceprocess}
\end{figure}

The execution flow is described as follows. Each action, from the activity
diagram, represents one or more function in the application. Each function or
service has an interface, consisting of its input and output, and how to call
this function/service. Thus, an activity must be executed according to the
rules identified in the use case model. For example, the
``\textit{publish music}'' action (figure \ref{fig:example_serviceprocess}), can
be refined into two flows: (i ) a flow to publish on Twitter and (ii) another to
update the Facebook, since each service has different rules for update and
login.

Given a set of services with their exported methods (known
in advance or provided by a service provider), building service-based
applications is a task that implies expressing an application logic as a service
composition together with some restrictions. Software engineering methods (e.g.,
\cite{CastroMV11,PapazoglouH06,sommerville08,Gervais02,somf,MilanovicM06})
can help to ensure the coherence between functional and non-functional
properties necessary to the system, particularly when information systems include
complex business processes calling web services or legacy applications exported
as services. The challenge is provide reliability for the complete application.


This example scenario will be used to conduct
the $\pi$SOD-M methodology and, model the system concepts from the use case to
service composition model. The structure of each model will be detailed in accordance
with their respective meta-model and transformations necessary for achieving the
aim of modeling reliable applications.


\section{Platform Independent Models}
\label{sec:pim-pisodm}


The \textit{Platform Independent Models (PIM)} are used for modeling the
structure of the system functionality and abstracting
technological details. These models can be used on
different deployment platforms. Since $\pi$SOD-M defines a method for developing
service-oriented applications, such models focus on identifying the services to be
offered by the system, as well as on identifying general functionalities,
processes and constraints.

The models proposed at $\pi$SOD-M's PIM level are: \textit{
$\pi$-UseCase, $\pi$-ServiceProcess} and \textit{
$\pi$-ServiceComposition} models. They express the design of:
(\textit{i}) system requirements and constraints; (\textit{ii}) external
services and its compositions; (\textit{iii}) execution flow; (\textit{iv})
input and output service restriction; (\textit{v}) services contract and
actions; and (\textit{vi}) policies for the implementation of business services.
The focus to use these models is provide a representation of the system by
specifying as much restrictions as possible, without considering the platform
where the application will run. Each design level refines the description of the
requirements and business specifications and their restrictions.


Each of the three Platform Independent Models are presented next.


\subsection{\textit{$\pi$-UseCase} Model}

Every application modelling approach has a departure point. After collecting the
application requirements through a requirements and business specification
document (as presented in figure \ref{fig:developmentProcess}), all this
information must be represented by models that will describe the system
structure and details for each service, component or function. The first model to be designed
in $\pi$SOD-M is the \textit{$\pi$-UseCase}.

 \textit{$\pi$-UseCase} model is used for modelling the
functionalities (services and general functionalities) required by the system. The services are
represented in this model as use cases. We propose to design this model by
means of the UML use cases with a small extension for considering constraints.
Application's constraints are represented by stereotyped use cases, and all
constraints, either application services and the constraints to be
respected by an application.

Considering the $\pi$SOD-M concepts, the
\textit{$\pi$-UseCase} meta-model describes the representation of
system functionalities to be modelled in this early stage of the design. The
system features and its interactions are presented using meta-model
entities. The $\pi$SOD-M concepts modelled in the \textit{$\pi$-UseCase}
meta-model are: {\sc Business Service, End Consumer, Requirement, Use Case,
Composite Use Case, Non-Functional Requirement, Non-Functional Attribute} and {\sc
Constraint}. The other concepts came from the original of use case model
specified by OMG \cite{UML}.

The main difference between the \textit{extended use case} model proposed by
SOD-M and \textit{$\pi$-UseCase} model is the inclusion of concepts that
represent the modeling of non-functional requirements (\textit{policy view}).

\begin{figure}[ht!]
\centering
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/PiUseCaseMetamodel.pdf}
\caption{$\pi$-UseCase Meta-model.}
\label{fig:usecasemodel}
\end{figure}

Figure \ref{fig:usecasemodel} presents the \textit{$\pi$-UseCase} meta-model and
the relationship between each concept. We highlight the elements that represent
the \textit{policy view}. The \textit{$\pi$-UseCase} elements
meta-model aims to describe system properties or information in a abstract way,
with a coarser granularity. The general features of the system and its
restrictions, do not considering any application details, as functions or
services' execution flow. Notice that some of the general methodology concepts
are present in \textit{$\pi$-UseCase} meta-model. For example, in the
\textit{$\pi$-UseCase} an {\sc End Consumer} is represented by an {\sc Actor}.
This means that a {\sc End Consumer} is modeled as an {\sc Actor} in the \textit{$\pi$-UseCase} model. An
{\sc Actor} is related to {\sc Use Cases}, which represent parts of a {\sc Business Service}. Thus, the
application features is modeled based on the models proposed by $\pi$SOD-M. So,
each element has its meaning in the model, and must be properly used to describe
system properties in a correct way.


A {\sc Business Service} composes a set of actions performed by the
system, and is represented as a aggregation of {\sc Use Cases}, while a {\sc
Composite Use Case} is a set of actions performed by the system which can be broken into different {\sc
Use Cases}. The {\sc Constraints}, represented by a stereotyped use case
(\textit{<<constraint>>}). {\sc Packages} represent {\sc Business Collaborators}
that interact with the application. {\sc Business Collaborators} simplicity of a
partnership to the complexity of a service corporation. Each {\sc Business Collaborators} combines
the features described in each {\sc Package}. Thus, the services functions can
be specified more intuitively, being grouped into packages.

The {\sc Non-Functional Requirement} and
{\sc Non-Functional Attribute} concepts are represented as
part of description of {\sc Use cases} and {\sc Constraints}. For model this
concepts the designer will use special tags to represent them.

The \textit{$\pi$-UseCase} meta-model
also represents the use of include and extend relations among the different use
cases identified. The semantics are the same as in the traditional UML use case
model. An include relation specifies the existence of a flow of events in which
the base use case includes the behaviour of the other use case and an extend
relation specifies that the behaviour of a base use case can be optionally
extended by the behaviour of another use case.

In summary, the main concepts to
be modelled at this level are: {\sc Constraints}, and its respective {\sc
Constraint Type}, and all {\sc Non-Functional Attribute} and {\sc Non-Functional
Requirement} associated to each {\sc Constraint}. These concepts are not
modelled in the original SOD-M extended use case model. Thus, we add these
constraint concepts in the \textit{$\pi$-UseCase} model.

An {\sc Use Case} may have several {\sc Constraints}. Each
{\sc Constraint} has its proper name, description, and which ones should be
checked during the execution of the application. Each {\sc Constraint} is
represented as a stereotyped (\texttt{<<constraint>>}) use case. A
restriction may be a restriction on data ({\sc Value Constraint}),
represented as the stereotype \texttt{<<value>>}; or on business rules
(\textit{Business Constraint}), represented as the stereotype
\texttt{<<business>>}; and {\sc Exceptional Behavior} constraints, which
represents constraint violation for the use case execution, represented as the stereotype
\texttt{<<exceptional\_behaviour>>}.


\begin{figure}[ht!]
\centering
\includegraphics[width=0.65\textwidth]{chapters/methodology/figs/umlRepresentation.pdf}
\caption{\textit{$\pi$-UseCase} Concepts Represented as UML Elements.}
\label{fig:umlrepresentation}
\end{figure}

Once described the meaning of each \textit{$\pi$-UseCase} concept in the
meta-model, it is important to know how specific models will be
created from this general representation. Every \textit{$\pi$-UseCase} model
created to describe application features and services must follow the
meta-model concepts. The \textit{$\pi$-UseCase} meta-model describes what can be
specified in each model, but how it will be described can be done in different
ways.


\begin{figure}[ht!]
  \centering
  \subfloat[\textit{Use Case} and \textit{Actor} Model]
  {\label{fig:piusecase1}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_usecase-actor_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
  \\
   \subfloat[\textit{Extended Use Case} Model]
  {\label{fig:piusecase2}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_extend_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
 \subfloat[\textit{Include Use Case} Model]
  {\label{fig:piusecase3}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_include_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
  \caption{\textit{$\pi$-UseCase} Model Representation}
  \label{fig:piuse_representation1}
\end{figure}

\begin{figure}[ht!]
  \centering
  \subfloat[\textit{Package} Model]
  {\label{fig:piusecase4}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_package_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Use Case}, \textit{Requirement} and
  \textit{Non-Functional Requirement} Model]
  {\label{fig:piusecase5}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_usecase-comments_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
  \\
  \subfloat[\textit{Constraint} Model]
  {\label{fig:piusecase6}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piusecase/pi_uc_constraint_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)

  \caption{\textit{$\pi$-UseCase} Model Representation (2)}
  \label{fig:piuse_representation2}
\end{figure}



In $\pi$SOD-M, we decided to design the models using UML specification
\cite{UML}. The \textit{$\pi$-UseCase} concepts are modelled as described in
figure \ref{fig:umlrepresentation} and the relationship between these concepts
is also applied to the UML elements. Figures \ref{fig:piuse_representation1} and
\ref{fig:piuse_representation2} details how to represent the relationship
between the meta-model concepts in a \textit{$\pi$-UseCase} model. The
\textit{approximately equal} symbol ($\approx$) used in figures
\ref{fig:piuse_representation1} and \ref{fig:piuse_representation2} means how
the \textit{$\pi$-UseCase} meta-model concepts (left side) can be modelled as an
UML model (right side).


An {\sc Actor} is an abstraction of the {\sc End
Costumer} concept, presented in $\pi$SOD-M meta-model. Thus, it is possible to
associate several {\sc Actors} with an {\sc Use Case} and many {\sc Use Cases} with an {\sc
Actor} ({\sc End Costumer}). The original use case meta-model defines
that {\sc Classifier} is a superclass of {\sc Actor}. A {\sc Classifier} is a
category of UML elements that have some common features, such as
\textit{attributes} or \textit{methods}. The relationship between these entities
is many to many (figure \ref{fig:piusecase1}). An  {\sc Use Case} can also be
related with an {\sc Extends} or an {\sc Include} entity in the \textit{$\pi$-UseCase} model, and
this model preserve the original UML standard semantic. {\sc
Extends} and {\sc Include} are types of stereotyped dependence relationships
(\texttt{<<extend>>} and \texttt{<<include>>} in figures \ref{fig:piusecase2}
and \ref{fig:piusecase3}, respectively). The {\sc Extends} relationship can modify the behaviour of the base use case. Suppose someone
wants to close a bank account, however still have some money there. Before
closing the account, there should be a withdrawal or transfer of money in this
account, so that the balance is zero. This process is modelled with a {\sc
Extends} dependence between the \textit{close account} use case and
the \textit{withdrawal money} and \textit{transfer money} use cases. The {\sc Include} relationship includes
the steps from one use case into another.

A {\sc Package} clause and its relationship with {\sc Use Case} and {\sc Actor}
 can be modelled in \textit{$\pi$-UseCase} model. The original semantics was
 preserved and it is possible have different levels of packages, due to  {\sc
 Package} entity auto reference, one to many. Each package can have many use
 cases and actors (\ref{fig:piusecase4}).

The {\sc Requirements}, {\sc Non-Functional Requirements} and {\sc Business
Services} must be associated with a specific {\sc Use Case}. At this level of modelling, these information are represented as
comment \textit{tags}, they are: \textit{\$ \ldots \$} for {\sc Requirements},
\textit{\# \ldots \#} for {\sc Non-Functional Requirements}, and \textit{\%
\ldots \%} for {\sc Business Service}. A {\sc
Business Service} is a aggregation of {\sc Use Case}, and each {\sc Use Case}
must be related with a system requirement {\sc Requirements}. Figure
\ref{fig:piusecase5} presents the relationship of this concepts, and how
represent this information in UML.

All {\sc Use Cases} may also be associated with a set of {\sc Constraints}. A
{\sc Constraint} is a stereotyped use case that describes the {\sc Constraint Type} and its
restriction. Additional information is given by comment tags, \textit{!
\ldots !} for {\sc Non-Functional Attribute}, and \textit{@
\ldots @} for candidate variables or values that must be checked during the
system execution, as presented in figure \ref{fig:piusecase6}. The relationship
between {\sc Use Cases} and  {\sc Constraint} is made by a non-stereotyped
dependence arrow.



\bigskip
\bigskip

Considering the example scenario, the ``\textit{update music}'' use case can
update the Facebook or twitter user status. Therefore, it is necessary to
perform a social network authentication with the user's data. Each social
network uses different services and different forms of authentication. The
``\textit{authentication}'' constraint is required to update a music status. The
restriction is stereotyped as a \texttt{<<value>>} constraint, because the
\textit{user's id} and \textit{password} are verified. The {\sc Non-Functional
Requirement} that is being modelled for this use case is \textit{Security},
because, considering  table \ref{tab:result04}, ``\textit{authentication}'' is
a {\sc Non-Functional Attribute} of \textit{Security}. These information will be
refined and detailed in the following phases.



\begin{figure}[ht!]
\centering
\includegraphics[width=.9\textwidth]{chapters/methodology/figs/piusecase/application/packages}
\caption{$\pi$-UseCase Scenario Example.}
\label{fig:usecasemodelpackages}
\end{figure}



Figure \ref{fig:usecaseContraint} shows
the model represented in figure \ref{fig:example_usecase} for the \textit{buy
music, download music, listen music} and \textit{pay} use cases. The model was
designed considering the meta-model representation detailed in figures
\ref{fig:piuse_representation1} and \ref{fig:piuse_representation2}, and also
the \textit{$\pi$-UseCase} meta-model. Notice that from  \textit{$\pi$-UseCase}
concepts is possible to describe the actors, use cases, constraints,
non-functional requirements and their attributes. For example, the \textit{pay}
use case (figure \ref{fig:usecaseContraint}), there are extended use cases, constraints, packages, non-functional requirements and non-functional
attributes related to this function. The modeling was based on the described
representation of the \textit{$\pi$-UseCase} meta-model. The extended use case
representation presented in figure \ref{fig:piusecase2} is used in the model to
expressed the \textit{pay by PayPal} and \textit{pay by card} extended use
cases. The include use case representation presented in figure \ref{fig:piusecase3} is
used in the model to expressed the included relation of \textit{buy music} and
\textit{pay} use cases. The package representation presented in figure
\ref{fig:piusecase4} is expressed in the example by the \textit{app.bank}
package and the \textit{pay} use case relation. The representation described in figures
\ref{fig:piusecase5} and \ref{fig:piusecase6} is expressed by the \textit{pay}
use case properties' description. The combination of a \textit{$\pi$-UseCase}
meta-model's entities means that all entities presented in figures
\ref{fig:usecasemodelpackages} and \ref{fig:usecaseContraint} can be modelled to
express the quality requirements.

The use cases that have restrictions are ``\textit{buy music}'' and
``\textit{pay}''. The process of buying a song requires the user's private data
for a Spotify account, and also a secure connection, represented as
\texttt{<<value>>} and \texttt{<<business>>} constraint, respectively. For
payment, the user must provide the data of payment card or PayPal account login
and password, represented as \texttt{<<value>>} stereotype . Other restriction
is that the minimum payment value is 2 euros. The {\sc Non-Functional
Requirement} that are being modelled for this use cases are \textit{Security}
and \textit{Reliability}. The specific {\sc Non-Functional Attributes} for this
restriction is \textit{Transaction} and \textit{Confidentiality} (see figure
\ref{fig:usecaseContraint}).


\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/methodology/figs/piusecase/application/packages2.pdf}
\caption{Use Case Model With Constraint Definition - Scenario Example Refined.}
\label{fig:usecaseContraint}
\end{figure}

% Each {\sc Constraint} may be related to {\sc Non-Functional
% Attributes}. These types are the attributes related to {\sc Non-Functional
% Requirement}. For example, \textit{security} is an {\sc Non-Functional Requirement} that
% comprises attributes such as \textit{Confidentiality} and \textit{Privacy}
% ({\sc Non-Functional Attribute}). Thus the use case constraints are always
% related to a {\sc Non-Functional Requirement} (figure
% \ref{fig:usecasemodel}).

\bigskip
\bigskip

After modeling the system services and features, and its
restrictions, it is necessary to model the services process and its
execution restrictions. For this, the methodology uses a service process diagram
to describe the services execution and contracts. Next we present the
\textit{$\pi$-ServiceProcess} model. This model refines the application
constraints through the workflow model.

\subsection{\textit{$\pi$-ServiceProcess} Model}


A \textit{Service Process} is a collection of related, structured activities or
tasks that produce a specific service or product for
a particular customer. It often can be visualized with a flowchart
as a sequence of activities with interleaving decision points.  A set of
linked activities that take an input and transform it to create an output.
Ideally, the transformation that occurs in the process should add value to the
input and create an output that is more useful and effective.

In the context of reliable service composition development, a \textit{Service
Process} can perform different third party functions services, so that
something new can be offered. Systems that use third party services add value
to the application because the services are already available and validated.
\textit{Service Process} modeling must complies with the application
requirements and the quality of service. If the services do not offer any
quality warranty, these quality requirements are the responsibility of the
application designer.

Based on this context, $\pi$SOD-M proposes modeling \textit{Service Process}
diagram (\textit{$\pi$-ServiceProcess} model), considering the functional and
non-functional requirements designed in the \textit{$\pi$-UseCase} model. 

The \textit{$\pi$-ServiceProcess} model represents the service processes and its
contracts. It models the set of system activities and it is
possible to describe contracts for each activity or the process as a whole. Each
service identified in the previous model (\textit{$\pi$-UseCase}) is mapped to
an {\sc Action}.

% Figure \ref{fig:serviceprocess} shows
% the \textit{$\pi$ServiceProcess} meta-model proposed by $\pi$SOD-M method for
% model \textit{Service Process}.

Considering the $\pi$SOD-M concepts (figure \ref{fig:pisodm-concepts}), the
\textit{$\pi$-ServiceProcess} meta-model (figure \ref{fig:serviceprocess})
describes the system functionalities to be modelled in a contract based service
process. The $\pi$SOD-M concepts modelled in the \textit{$\pi$-ServiceProcess}
meta-model are: {\sc Contract, Assertion, Exceptional Behaviour, Activity,
Service Activity, Action} and {\sc Constraint}.
 
 \begin{figure}[ht!]
\centering
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/PiServiceProcess.pdf}
\caption{$\pi$-ServiceProcess Meta-model.}
\label{fig:serviceprocess}
\end{figure}

Restrictions on activities and services are not described in the
original SOD-M proposal. The concepts of {\sc Contract, Assertion} and
{\sc Exceptional Behaviour} make possible to model restrictions on services
execution, ensuring greater reliability application. Entities highlighted in
\textit{$\pi$-ServiceProcess} meta-model (figure \ref{fig:serviceprocess})  are
the difference from the original SOD-M service process model.


A specific \textit{$\pi$-ServiceProcess} model shows the set of logically
related activities that need to be performed in a service-based system. So, the
activities of this model represent a behaviour that is part of the
system workflow. $\pi$SOD-M proposes representing this model using
the UML activity diagram, with an extension for {\sc Contract} design,
which encapsulates several {\sc Constraints} modelled in \textit{$\pi$-UseCase}
model. In \textit{$\pi$-ServiceProcess}, three main features are
represented: (i) \textit{service process}, (ii) \textit{service activity} and
(iii) \textit{activity contract}. The service process is represented by the
model itself. A service activity represents a behaviour that is part of the
execution flow, and is identified in this model as an {\sc Action}. A activity
contract represents the {\sc Non-Functional Requirement} behaviour that is also
part of the execution flow of a service, and is identified in this model as an
stereotyped activity (\texttt{<<assertion>>}). All {\sc Assertion} related with
an {\sc Action} compose a {\sc Contract}. From the {\sc Contract} and {\sc
Assertion} concepts is possible to define the interface specifications
for each activity service, such as pre-conditions and post-conditions.



\begin{figure}[ht!]
  \centering
  \subfloat[\textit{Assertion} Model]
  {\label{fig:pisp1}\includegraphics[width=0.5\textwidth]{chapters/methodology/figs/piserviceprocess/assertion_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \subfloat[\textit{Contract} Model]
  {\label{fig:pisp2}\includegraphics[width=0.5\textwidth]{chapters/methodology/figs/piserviceprocess/contract_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Exceptional Behaviour} Model]
  {\label{fig:pisp3}\includegraphics[width=0.5\textwidth]{chapters/methodology/figs/piserviceprocess/exceptionalBeh_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \subfloat[\textit{Action} Model]
  {\label{fig:pisp4}\includegraphics[width=0.5\textwidth]{chapters/methodology/figs/piserviceprocess/action_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Service Activity} Model]
  {\label{fig:pisp5}\includegraphics[width=0.5\textwidth]{chapters/methodology/figs/piserviceprocess/serviceActivity_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)

  \caption{\textit{$\pi$-ServiceProcess} Model Representation}
  \label{fig:pisp_representation}
\end{figure}


\begin{figure}[ht!]
  \centering
  \subfloat[\textit{Control Nodes} Model]
  {\label{fig:pisp6}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piserviceprocess/controlNode_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Activity Edge - Control Flow} Model]
  {\label{fig:pisp7}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piserviceprocess/activityEdge_final}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
  \\
  \subfloat[\textit{Activity Edge - Control Object} Model]
  {\label{fig:pisp8}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piserviceprocess/activityEdge2_final}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)

  \caption{\textit{$\pi$-ServiceProcess} Model Representation (2)}
  \label{fig:pisp_representation2}
\end{figure}


To formalize the concept of {\sc Contract} by rules, we use the definition of
{\sc Assertion} (figure \ref{fig:pisp1}). An {\sc Assertion} is represented by a
stereotyped action (\texttt{<<assertion>>}), and {\sc Assertion Properties}
through comments. An {\sc Assertion} may be a \textit{pre-condition},
\textit{post-condition} or a \textit{time restriction} over the service
execution ({\sc Assertion Property}). These information are represented as
the comment \textit{tags} \textit{\$ \ldots \$}. The assertion predicate is
modelled as \textit{\# \ldots \#} tag. Figure \ref{fig:pisp1} shows how these
concepts are represented in UML.

A set of {\sc Assertion} composes a service {\sc Contract} and is
represented as this set of {\sc Assertion} related with a {\sc Action}
(figure \ref{fig:pisp2}).  An Assertion describes value (\textit{value
constraint} from $\pi$-UseCase model) restrictions, setting maximum and minimum
limits, or business restrictions, setting conditions for function calls
((\textit{business constraint} from $\pi$-UseCase model)). The
business restrictions are over service functions. Every service contract may
have an exception behaviour, if a constraint is not obeyed. For example, if the
user card information are incorrect, the service is called again until the limit
of 3 calls, otherwise, execution continues normally. In this case, the exception
is the new call to the same service. For this, we also use the concept of {\sc
Exceptional Behaviour} (figure \ref{fig:pisp3}). A {\sc Exceptional Behaviour}
is also a stereotyped action (\texttt{<<exceptional behaviour>>}) and its
properties are modelled through comment tags. The condition to be verified is
modelled as \textit{\# \ldots \#} tag. Figure \ref{fig:pisp1} shows how these
concepts are represented in UML. If the condition is \textit{false}, the
predicate becomes true, because of the expression negation
(\textit{not}). Thus the action is performed. The action to be performed is
modelled as \textit{! \ldots !} tag. The {\sc Action} concept is modelled in UML
as the action component (figure \ref{fig:pisp4}), and a {\sc Service Activity}
represents a set of {\sc Action} (figure \ref{fig:pisp5}). These
representations describe which is possible to design in a service process model.
We highlight the models in figures \ref{fig:pisp1}, \ref{fig:pisp2} and
\ref{fig:pisp3}, because present how a assertion action, a contract, and a
exceptional behaviour can be designed.

Figure\ref{fig:pisp_representation2}
show the UML representation of the {\sc Control Nodes} and {\sc Activity Edges}
concepts in $\pi$-ServiceProcess meta-model. This representation follow the
original UML specification. Figure \ref{fig:pisp6} presents the
{\sc Control Nodes} and how its can be applied in a real modelling, and finally
figures \ref{fig:pisp7} and \ref{fig:pisp8} show the {\sc Activity Edges} and
its application. 

% These model concepts is very important, because it is from
% the restrictions described in the previous model ($\pi$-UseCase) that each
% constraint begins to be refined and applied to real application services. 


\bigskip
\bigskip 


Considering the example scenario, the contract based process of activities
execution is shown in figure \ref{fig:serviceprocessContract}.
The activities flow in figure \ref{fig:example_serviceprocess} presents any restriction. Thus, it is necessary
to represent each {\sc Constraint} modelled in a more representative {\sc
Contract} based service activity diagram.

Based on the concepts described and its representation in UML, we describe how
to model a service process using the assertions as restriction for each action.
The difference of the model shown in figure \ref{fig:example_serviceprocess}
and the figure \ref{fig:serviceprocessContract} is that were added restrictions
on the actions in order to describe quality requirements.


\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/methodology/figs/piserviceprocess/runningExampleSP_final.pdf}
\caption{Service Process Model with Contract Definition - Complete Example.}
\label{fig:serviceprocessContract}
\end{figure}

% \begin{figure}[ht!]
% \centering
% \includegraphics[width=.89\textwidth]{chapters/methodology/figs/piserviceprocess/runningExampleSP_part.pdf}
% \caption{Service Process Model with Contract Definition}
% \label{fig:serviceprocessContractPart}
% \end{figure}



Each {\sc Use Case} modelled in the use case diagram are refined into {\sc
Actions} in the service process diagram. The set of {\sc Constraints} are
transformed into {\sc Assertions} and {\sc Contracts}. The \textit{buy music}
and \textit{publish music} services (update Twitter and Facebook) has pre- and
post-conditions assertions that are composed into a contract for each service. 
 The  \textit{buy music} pre-conditions are: (i) verify if the User
data are correct; (ii) if the User is already logged in Spotify; (iii) if bank
account information are correct and; (iv) if there is enough money to make the
payment. As post-condition, it ensures the complete transaction and verify if a
notification were sent to the user and Spotify, about the payment authorization.
There are four assertion for \textit{buy music} action, and each assertion has
been detailed with the assertion property and predicate that must be verified. 
To \textit{update} services, depending of each service, there may be different
restrictions. As an example, a new verification of user data and message format
is appropriate (maximum 140 characters), in case of Twitter. In the case of Facebook, it is required that
the user is already logged on Spotify and these data are the same as
Facebook. As post-condition, it ensures that the Facebook service send a
notification of success. To update the Twitter is only required
pre-conditions, while to update the Facebook is a necessary precondition and a
confirmation notice as post-condition. As a precondition for ``\textit{twitter
update}'' it is necessary that \textit{(i)} the music format is correct and
(\textit{ii})  the twitter login and password is correct for the update.


\bigskip
\bigskip

After modeling of service process, its features, and the
service contracts, it is necessary to model the service composition process and
its policies. $\pi$SOD-M uses a service composition diagram
to describe the third party services and each policy allied to
each composition. In the next section we present this model and their respective
policy concept.
 
\subsection{$\pi$-ServiceComposition Model}

The $\pi$-ServiceComposition model refines the concepts described in the
$\pi$-ServiceProcess model
(figure \ref{fig:serviceprocessContract}). The service composition model represents the
workflow needed to carry out a service, but in a more detailed way,
\textit{i.e.}, identifying those entities that collaborate in the business
processes, performing some of the actions that are necessary to carry out the business services (the
business collaborators), and the actions each of them performs. Each
action identified in this model describes a fundamental behaviour
unit that is part of a service activity and represents some transformation
or processing in the system being modelled. $\pi$SOD-M also proposes
representing this model using the a extension of UML activity diagram technique.
This extension describes the relationship of each {\sc Action} for the
respective {\sc Service Activities}. Thus, as shown in figure
\ref{fig:servicecomposition}, the meta-model includes typical modeling elements
of the activity diagram such as {\sc Activity Nodes}, {\sc Initial
Nodes} and {\sc Final Nodes}, {\sc Decision Nodes}, etc., along with
new elements defined by $\pi$SOD-M such as {\sc Business Collaborator},
{\sc Service Activity} and {\sc Action} (see
figures \ref{fig:servicecomposition} and \ref{fig:servicecompositionPolicy}).

All \textit{$\pi$-ServiceComposition} models
describe the set of services and its relation with the service process and its
activities that need to be performed. So, the external services
are represented by the {\sc Business Collaborator} concept. All service
composition may specify a {\sc Policy} as restriction. A {\sc Policy} is the
set of {\sc Contracts} related with the service process expressed in the
previous model (\textit{$\pi$-ServiceProcess}).

\begin{figure}[ht!]
\centering
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/PiServiceComposition}
\caption{$\pi$ServiceComposition Meta-model.}
\label{fig:servicecomposition}
\end{figure}

Considering the $\pi$SOD-M concepts (figure \ref{fig:pisodm-concepts}), the
\textit{$\pi$-ServiceComposition} meta-model (figure
\ref{fig:servicecomposition}) describes the service compositions
to be modelled and the policies related with each service composition.
The $\pi$SOD-M concepts modelled in the \textit{$\pi$-ServiceComposition}
meta-model are: {\sc Policy, Rule, Variable, Exceptional Behaviour, Service
Activity, , Action, Business Collaborator} and {\sc Non-Functional
Requirement}.

Policy over service activities and business collaborators are not described in
the original SOD-M method. The rule concept grouped into policy and
exceptional behavior make possible to model restrictions on service composition. Entities
highlighted in the \textit{$\pi$-ServiceComposition} (figure
\ref{fig:servicecomposition}) meta-model are the difference from the original
SOD-M service composition model.

A {\sc Business Collaborator} element represents those
entities that collaborate in the business processes by
performing some of the required actions. They are graphically
presented as a partition in the activity diagram.
A collaborator can be either internal or external to the
system being modelled. When the collaborator of the
business is external to the system, the attribute \textit{IsExternal} of the
collaborator is set to \textit{true}.

{\sc Action}, a kind of {\sc Executable Node}, are represented
in the model as an activity. Each action identified in
the model describes a fundamental behaviour unit which
represents some type of transformation or processing
in the system being modelled. There are two types of
actions: i) a Web Service (attribute Type is \textit{WS}); and ii) a
simple operation that is not supported by a Web Service,
called an {\sc Activity Operation} (attribute Type is \textit{AOP}).

The {\sc Service Activity} element is a composed activity
that must be carried out as part of a business service and
is composed of one or more executable nodes.


The policy based service composition model refines the concept contract of
service process model. A policy assemble a set of contracts and can be
applied to more than one activity. The restriction on service composition model
is marked with the stereotype \texttt{<<policy>>}.

\begin{figure}[ht!]
  \centering
  \subfloat[\textit{Service Activity} and \textit{Business Collaborator}  Model]
  {\label{fig:pisc1}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piservicecomposition/serviceComposition1}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Policy} and \textit{Rule}  Model]
  {\label{fig:pisc2}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piservicecomposition/serviceComposition3}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
  \\
  \subfloat[\textit{Business Collaborator - External false} Model]
  {\label{fig:pisc3}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piservicecomposition/serviceComposition2}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[\textit{Business Collaborator - External true} Model]
  {\label{fig:pisc4}\includegraphics[width=0.8\textwidth]{chapters/methodology/figs/piservicecomposition/serviceComposition4}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \caption{\textit{$\pi$-ServiceComposition} Model}
  \label{fig:picomposition_representation}
\end{figure}

An {\em Policy} groups a set of rules. It describes global variables and
operations that can be shared by the rules and that can be used for expressing
their Event  and Condition parts. An {\em Policy} is associated to the
elements {\sc Business Collaborator}, {\sc Service Activity} and, {\sc Action}  of
the $\pi$-ServiceComposition meta-model (see figure
\ref{fig:servicecomposition}) .

Instead of programming different protocols within the application logic, we
propose to include the modeling of non-functional requirements like
transactional behaviour, security and adaptability at the early stages of the
services' composition engineering process.

The representation described in figure \ref{fig:picomposition_representation}
presents how the methodology's user apply the concepts described in the
\textit{$\pi$-ServiceComposition} meta-model. Each meta-model entity has a
meaning for modeling service composition and its policies. In the specific case
of \textit{$\pi$-ServiceComposition} meta-model, those concepts will be used to
describe how {\sc Business Collaborator, Action, Service Activity, Policy and
Rules} can be specified. Figure \ref{fig:picomposition_representation}
also describes how the proposed concepts can be modelled in real system
development cases. All \textit{$\pi$-ServiceComposition} based models
(presented in figure \ref{fig:picomposition_representation}) must follow the
meta-model description and its constraints.


Figure \ref{fig:pisc1} presents the representation for the relation between
{\sc Action} and {\sc Business Collaborator}. As a {\sc Service Activity} are
modelled as a set of {\sc Actions} (service functions), they are represented as
\textit{<<External true>>} {\sc Business Collaborator}. It means that an
external service are invoke by the application's function. Each {\sc Business
Collaborator} represents an external service. Figure \ref{fig:pisc2} presents the
representation for the relation between {\sc Action}, {\sc Policy} and {\sc
Rule}. Figure \ref{fig:pisc3} presents the representation of the original
\textit{Service Process} associated to the \textit{<<External false>>} {\sc
Business Collaborator} and figure \ref{fig:pisc4} presents how associate the
\textit{Service Process}' {\sc Action} with real services.

Notice that all \textit{$\pi$ServiceComposition} meta-model concepts can be
represented in the real application model, as we illustrate next using the
scenario example.

\bigskip
\bigskip

To illustrate the use of the model we used it for defining the
policy based composition model of the example scenario (see figure
\ref{fig:servicecompositionPolicy}). There are four external {\sc Business
Collaborators}, they are: \textit{Bank, Spotify, Twitter} and \textit{Facebook}.
The model also shows the business process of the application that consists of
six {\sc Service Activities} (see figure \ref{fig:example_serviceprocess}):
\textit{search music, select music, buy music, download music, listen music} and
\textit{publish music}. Note that the action \textit{publish music} of the
application calls the actions of two service collaborators namely Facebook and
Twitter, and the action \textit{buy music} of the application calls two actions
of the service collaborators namely Bank.

\begin{figure}[ht!]
\centering
\includegraphics[width=.99\textwidth]{chapters/methodology/figs/runningExampleServiceComposition.pdf}
\caption{Service Composition Model with Policy Definition - Spotify Music
Service.}
\label{fig:servicecompositionPolicy}
\end{figure}


Given that {\em Facebook} and {\em Twitter} services require authentication
protocols in order to execute methods that will read and update the users'
space. A call to such services must be part of the authentication protocol
required by these services. In the example we  associate two authentication
policies, one for the open authentication protocol, represented by the class
{\sf\small Twitter AuthPolicy} that will be associated to the activity
{\sf\small UpdateTwitter} (see figure \ref{fig:servicecompositionPolicy}). In
the same way, the  class {\sf\small Facebook HTTPAuthPolicy}, for the http
authentication protocol will be associated to the activity {\sf\small
UpdateFacebook}. {\sf\small OAuth}  implements the open authentication protocol.
As shown in figure \ref{fig:servicecompositionPolicy}, the {\em Policy} has a
variable {\sf\small Token} that will be used to store the authentication token
provided by the service. This variable type is imported through the library
{\sf\small Auth.Token}. The {\em Policy}  defines two rules, both can be
triggered by events of type {\sf\small ActivityPrepared}: (i) if no token has
been associated to the variable {\sf\small token}, stated in by the condition of
rule {\sf\small R$_1$}, then a token is obtained (action part of {\sf\small
R$_1$}); (ii) if the token has expired, stated in the condition of rule
{\sf\small R$_2$}, then it is renewed (action part of {\sf\small R$_2$}). Note
that the code in the actions profits from the imported  {\sf\small Auth.Token}
for transparently obtaining or renewing a token from a third party.
 
{\sf\small HTTP-Auth} implements the HTTP-Auth protocol.  As shown in figure
\ref{fig:servicecompositionPolicy}, the {\em Policy} imports an http protocol
library and it has two variables {\sf\small username} and {\sf\small password}.
The event of type {\sf\small ActivityPrepared} is the triggering event of the
rule {\sf\small R$_1$}. On the notification of an event of that type, a
credential is obtained using the username and password values. The object
storing the credential is associated to the scope, i.e., the activity that will
then use it for executing the method call.

\bigskip
\bigskip

Thanks to rules and policies it is possible to model and associate
non-functional properties to services' compositions  and then generate the code.
For example, the atomic integration of information retrieved from different
social network services, automatic generation of an integrated view of the
operations executed in different social networks or for providing security in
the communication channel when the payment service is called.

Back to the  definition process of a SIS, once the {\em Policy} based services'
composition model has been defined, then it can be transformed into a model
(i.e., $\pi$-PEWS model, Section \ref{sec:psm-pisodm}) that can support then
executable code generation. The following Section describes the $\pi$-PEWS
meta-model that supports this representation.

\section{$\pi$-PEWS Platform Specific Models}
\label{sec:psm-pisodm}


$\pi$SOD-M perform a model proposes at PSM level, which combine
specific details of the service-based platforms. We use a $\pi$-PEWS language meta-model for represent the
specification of a service composition on the language. From models described in PEWS, the code can be automatically
generated. We extend the PEWS language, and named the its extension as
$\pi$-PEWS (see Appendix \ref{append:pews_language}), and aggregate to it
constructs for specifying policies for services through contracts clauses.


Platform specific models (PSMs) are used to combine the specifications in
the PIM with the details of the chosen platform for system implementation. PSM
models will be used to implement the system (generating code automatically), and this must provide all
information needed to build the system and its components. However, a PSM
model can also run as a model to be used for further refinements by others PSM
models.

The idea of the $\pi$-{\sc Pews} meta-model is based on the services'
composition approach provided by the language $\pi$-PEWS
\cite{BaAM06,Placido2010LTPD} (\textit{Path Expressions for Web Services}), a programming language that lets the service designer  combine the methods or subprograms that implement each operation of a service, in order to achieve the desired application logic. Figure \ref{fig:metamodel} presents the $\pi$-{\sc Pews} meta-model consisting of  classes representing:
\begin{itemize}
\item A services' composition: {\sc Namespace} representing the interface exported by a service, {\sc Operation} that represents a call to a service method, {\sc Composite Operation}, and  {\sc Operator} for representing a services' composition and {\sc Path} representing a services' composition.
A {\sc Path} can be an {\sc Operation} or a {\sc Composite Operation}
denoted by an identifier. A {\sc Composite Operation} is defined using an  {\sc Operator}  that can be represent  sequential ($\ . \ $) and parallel ($\ \| \ $) composition of services,
choice ($\ + \ $) among services,
the sequential ($*$) and parallel ($\{\dots\}$) repetition of an operation or the conditional execution of an operation ($[C]S$).

\item {\em Policies} that can be associated to a services' composition:  {\sc A-Policy}, {\sc Rule}, {\sc Event}, {\sc Condition}, {\sc Action}, {\sc State}, and {\sc Scope}.
\end{itemize}
 
\begin{figure}[ht!]
\centering
\includegraphics[width=1.0\textwidth]{chapters/methodology/figs/PEWSMetamodel}
\caption{$\pi$-PEWS Meta-model.}
\label{fig:metamodel}
\end{figure}

As shown in the diagram an {\sc Policy} is applied to a {\sc Scope} that can be
either an {\sc Operation} (e.g., an authentication protocol associated to a
method exported by a service),  an {\sc Operator} (e.g., a temporal constraint
associated to a sequence of operators, the authorized delay between reading a
song title in Spotify and updating the walls must be less then 30 seconds), and
a {\sc Path} (e.g., executing the walls' update under a strict atomicity
protocol -- all or noting).  It groups a set of ECA rules, each rule having a
classic semantics, i.e, {\em when an event of type E occurs if  condition C is
verified then execute the action A}.  Thus, an {\em Policy} represents a set of
reactions to be possibly executed if one or several triggering events of its
rules are notified.

\begin{itemize}
\item The class {\sc Scope} represents any element of a services' composition (i.e., operation, operator, path).
\item The class {\sc Policy} represents a recovery strategy implemented by ECA
rules of the form {\sc Event} - {\sc Condition} - {\sc Action}. A {\em Policy}
has variables that represent the view of the execution state of its associated
scope, that is required for executing the rules. The value of a variable is
represented using the type {\sc Variable}. The class {\sc Policy} is specialized
for defining specific constraints, for instance authentication {\em Policies}.
\end{itemize}

Given a $\pi$-ServiceComposition model of a specific services' based application
(expressed according to the $\pi$-ServiceComposition meta-model), it is possible
to generate its corresponding $\pi$-PEWS model thanks to transformation
rules. The following Section describes the transformation rules between the
$\pi$-ServiceComposition and $\pi$-PEWS meta-models of our method.

The $\pi$-PEWS language (extension of PEWS) is described in the Appendix
\ref{append:pews_language}. The generated code by $\pi$SOD-M, as end product, is
based on the meta-model shown in figure \ref{fig:servicecomposition} and the
language syntax.


\section{Models Transformation}
\label{sec:models-tranformation}

A model transformation usually specifies which models are acceptable as input,
and if appropriate what models it may produce as output, by specifying the
meta-model to which a model must conform. Model transformations can be thought
of as process that take models as input and produces a model as output. There
is a wide variety of kinds of model transformation and uses of them, which differ in their inputs and outputs
and also in the way they are expressed \cite{miller}.   

A model transformation is also a way of ensuring that a family of models is
consistent, in a precise sense which the software engineer can define. The aim
of using a model transformation is to save effort and reduce errors by
automating the building and modification of models where possible
\cite{atl_manual}.

The $\pi$SOD-M model transformations occur in the two level, PIM and PSM,
and there may be transformations as:  PIM-to-PIM and
PIM-to-PSM. Transformation in the same level are considered
``horizontal transformation'', \textit{e.g.} PIM-to-PIM transformation, and
transformation in different levels are ``vertical transformation'',
\textit{e.g.} PIM-to-PSM transformation. There are 3
transformation models in $\pi$SOD-M, they are: $\pi$-UseCase to
$\pi$-ServiceProcess; $\pi$-ServiceProcess to $\pi$-ServiceComposition; and $\pi$-ServiceComposition
to $\pi$-PEWS.

\begin{figure}[ht!]
  \centering
  \subfloat[From one A to one B]
  {\label{fig:rule01}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule01}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
   \subfloat[From many A to many B]
  {\label{fig:rule02}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule02}}
  ~
   \subfloat[From many A to one B]
  {\label{fig:rule03}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule06}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
 \subfloat[From one A to one B, and one C]
  {\label{fig:rule04}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule03}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  ~
   \subfloat[From many A to many B, and one C]
  {\label{fig:rule05}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule04}}
  ~
   \subfloat[From many A to many B, and one C]
  {\label{fig:rule06}\includegraphics[width=0.33\textwidth]{chapters/implementation/figs/rule05}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \caption{Entities' Model Transformation Rules}
  \label{fig:rules}
\end{figure}




 All $\pi$SOD-M transformation rules will be described in natural language and
 these transformations ensure consistency between the concepts being refined and
 processed at different levels. Figure \ref{fig:rules} presents the set of rules
we defined to apply for each type of transformation. The entities from left
represents the source model, and those on the right represents the target model elements. Figure \ref{fig:rule01} shows the
transformation rule which a single source entity is transformed in a target model entity. Figure
\ref{fig:rule02} describes a many to many entity transformation, a set of
objects from the source model is transformed in a set of objects in the target
model. Figure \ref{fig:rule03} presents a many to one transformation rule, from many
objects in the source model, it will be transformed in a single object element
in the target model. The next 3 rules are advanced rules, which from a single
element in the source model, a set of different elements can be generated in the
target model. In figure \ref{fig:rule04}, from a source element, it will be
transformed in two different ones, \textit{e.g.} from a ``\textit{A}'' element,
it generates a ``\textit{B}'' and a ``\textit{C}'' element in the target model.
In figure \ref{fig:rule05}, from a set of source elements, it will be
transformed in a set of elements ``\textit{B}'' and one ``\textit{C}'' element
in the target model. Finally, figure \ref{fig:rule06} presents the rule which
from a source elements, it will be transformed in a set of elements
``\textit{B}'' and one ``\textit{C}'' element in the target model.

\subsection{From $\pi$-UseCase to
$\pi$-ServiceProcess}

The transformation process between $\pi$-UseCase and $\pi$-ServiceProcess (Table \ref{tab:transformationUseCaseToServiceProcess})
models represents how the application requirements are represented as a
service process. At this level, services and general function are represented as
simple and composite use cases. 

Every {\sc Use Case} are transformed in
a {\sc Action} in the \textit{$\pi$-ServiceProcess} model, and every {\sc
Extend} association identified in the \textit{$\pi$-UseCase model} are
transformed in a {\sc Fork Node}. If the extend association has only one 
{\sc Use Case}, the fork will present the {\sc Action} as an alternative flow,
and later, both flows will meet. If the extend association has several source
{\sc Use Case}, the fork will present different {\sc Actions} as mutual
alternatives flows, and later, all these flows will meet. A {\sc Activity
Services} (from $\pi$-ServiceProcess meta-model) consists of a composition of
one or more {\sc Actions}. {\sc Action} can be viewed as functions (methods) of
the system application. Thus, services are represented as a set of functions in
the \textit{$\pi$-ServiceProcess} meta-model, because {\sc Contracts} modelled
are over functions ({\sc Actions}).

All {\sc Constraints} in the source model (\textit{$\pi$-UseCase model}) are
transformed into a {\sc Contract}. A {\sc Contract} is represented as a set of {\sc Constraints}. Each
constrains description is directly transformed in a {\sc Assertion}. A set of
{\sc Constraint} of a {\sc Use Case} or a {\sc Composite Use Case} are transformed
in a set o {\sc Assertion} that will be assembled in a {\sc Contract}. All
{Use Cases} that are associated to a {\sc Non-Functional Requirement} and all
{\sc Constraints} are associated with a {\sc Non-Functional Attribute}. Thus,
{\sc Constraint} representing the same {\sc Use Case}, will be transformed in a
{\sc Contract}. A {\sc Contract} can have exceptional cases. The negation of the
{\sc Constraint} predicate are treated as a {\sc Exceptional Behavior}. In this
particular case, a {\sc Exceptional Behavior} will be generated in the target
model. 

The {\sc Constraint Type} can have different transformations, depending of the
following values:

\begin{itemize}
\item If the value of {\sc Constraint Type} is \textit{BUSINESS}, it will be
transformed into none {\sc Assertion};
\item If the value of {\sc Constraint Type} is \textit{VALUE} with the
{\sc Assertion} \textit{isExceptionalBehavior} attribute setted to
\textit{false}, it will be transformed into one {\sc Assertion};
\item If the value of {\sc Constraint Type} is \textit{VALUE} with the
{\sc Assertion} \textit{isExceptionalBehavior} attribute setted to
\textit{true}, it will be transformed into a {\sc Exceptional Behavior};
\end{itemize}

\begin{table}[ht!]
\tiny
\renewcommand{\arraystretch}{1.3}
\caption{Transformation Rules: From $\pi$-UseCase to $\pi$-ServiceProcess}
\label{tab:transformationUseCaseToServiceProcess}
\centering
\begin{tabular}{l|l|l}
    \hline
    Source  &  Mapping Rules & Target\\
    $\pi$-UseCase meta-model  &   & $\pi$-ServiceProcess meta-model\\
    \hline
    \hline

    Use Case   &  For every basic \textbf{Use Case} there will be a
    \textbf{Action} in the service delivery process model & Action  \\
    & describing the Business Service &   \\

    \hline

    Extend (Use Case)    & - Every \textbf{Extend} association identified in the
     \textit{$\pi$-UseCase model} will be represented in the target model   & Control Node, \\
     &by a \textbf{Fork Node}.&  Fork Node,\\
      & - The \textbf{Service Activity} corresponding to the source
      \textbf{ Use Case} of the extend association must be  & Service
      Activity
    \\

      & previous to the \textbf{Service Activity} corresponding to the
      target \textbf{ Use Case} of the extend association. &\\

        &  - If the extend association has only one source \textbf{
        Use Case}, the fork will present the \textbf{Service} & \\
        &\textbf{ Activity} as an alternative to another flow with no \textbf{Service Activity}. Later, both flows will meet;&\\

       &  - If the extend association has several source \textbf{
        Use Case}, the fork will present the different \textbf{Service} & \\
        &\textbf{Activities} as mutual alternatives to another flow with no
        \textbf{Service Activity}. Later, all these flows will&\\
        &meet;&\\
    \hline

      Include (Use Case)    & - An \textbf{Include} association is found in the
      \textit{$\pi$-UseCase model},  the \textbf{Service Activity} corresponding to the    &
      Service Activity \\
       &source must be subsequent to the \textbf{Service Activity} corresponding
       to the target \textbf{ Use Case} of the & \\
      &include association;&\\

        &  - If the include association has several targets, the designer must
        decide the appropriate sequence & \\
        & for the different \textbf{Service Activities} corresponding to the
        target  \textbf{ Use Case} (which will obviously&\\

        &  be previous to the \textbf{Service Activity} corresponding to the
        source \textbf{ Use Case}).&\\

\hline

	Requirement & - A \textbf{Requirement} in the source model is transformed into
	\textbf{Service Activity} of the target model. & Service Activity
	\\ & - The rules for a \textbf{Requirement} to be transformed into a  &\\
	& service activity is analyzed after the transformations of included and
	extended use cases.&\\
	 &- A \textbf{Requirement} associated with only one \textbf{Use Case} in the
	 source model is transformed in a.&\\
	 &\textbf{Service Activity} and an \textbf{Action}, respectively. &\\
	&- All \textbf{Use Cases} must be associated with a \textbf{Requirement}.&\\

\hline

	Constraint & - All \textbf{Constraints} in the source model will be transformed
	into a \textbf{Assertion} in the target model.  & Assertion, Contract, \\
	 & All \textbf{Use Cases} are associated to a \textbf{Non-Functional
	 Requirement} and all \textbf{Constraints} & Exceptional Behaviour   \\
	 &are associated with a \textbf{Non-Functional Attribute}. Thus,
	 \textbf{Constraint} representing the same Use Case,  &  \\
	& is transformed in a \textbf{Contract}. & \\
	& - A \textbf{Contract} can also have a exceptional cases. The negation of the
	\textbf{Constraint} predicate are treated &\\

	& as the type \textit{EXCEPTIONALBEHAVIOUR}. Thus, all the \textbf{Assertions}
	related to this \textbf{Constraint},  &\\

	&in this particular case, will be transformed in a \textbf{Exceptional
	Behavior}.&\\
	& - The set of {\sc Assertions} of a {\sc Use Case} are associated with a
	{\sc Contract} & \\
	& - The {\sc Contract} name is formed by ``<useCaseName>'' + ``Contract''
	token. & \\
\hline


	 Constraint Type & - The \textbf{Constraint Type} in source model can have the
	 following transformation: & Assertion\\

	   &  $\bullet$ \textbf{BUSINESS} type is transformed into none
     \textbf{Assertion}; &  Exceptional Behaviour\\

      &  $\bullet$ \textbf{VALUE} with the
     \textbf{Assertion} \textit{isExceptionalBehavior} attribute setted to false
      is transformed into& \\
     & a \textbf{Assertion} in the target model;&\\

      &  $\bullet$ \textbf{EXCEPTIONALBERAVIOR} with the
      \textbf{Assertion} \textit{isExceptionalBehavior} attribute setted  & \\
      &to true is transformed into a \textbf{Exceptional Behavior} in the target
      model.&\\


    & - Both, the  value and exceptional restriction are based on in accordance
    with the values&\\
    & of \textbf{Assertions}&\\

    & - \textbf{Constraint Type} defines the type of restriction on a
    \textbf{Use Case}. &  \\

% \hline
%
% 	Assertion, & Every \textbf{Assertion} associated to an element (\textbf{Assertion
% 	Property} and \textbf{Constraint}) in the source  & Assertion, \\
% 	Assertion Property & model becomes an \textbf{Assertion} associated to the
% 	corresponding element in the target model. & Assertion Property \\
%
\hline

	Non-Functional & Every \textbf{Non-Functional Attribute} associated to an
	element (\textbf{Constraint} and \textbf{Non-Functional} &
	Non-Functional \\ Attribute &  \textbf{Requirements}) in the source model
	becomes a \textbf{Non-Functional Attribute} associated to the  &
	Attribute \\
	&corresponding element (\textbf{Contract}) in the target model. &\\
\hline
\end{tabular}
\end{table}



\begin{figure}[ht!]
  \centering
  \subfloat[From \textit{Use Case} and \textit{Constraint} to \textit{Action}
  and \textit{Contract}]
  {\label{fig:trans01}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans01}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
   \subfloat[From \textit{Constraint} to \textit{Contract} (2)]
  {\label{fig:trans02}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans06}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[From \textit{Composite Use Case} to \textit{Service Activity}]
  {\label{fig:trans03}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans03}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank
   % line to force the subfig onto a new line)
  \subfloat[From \textit{Requirements} to \textit{Service Activity}]
  {\label{fig:trans04}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans02}}
  \caption{$\pi$-UseCase2$\pi$-ServiceProcess Model Transformation Rules}
  \label{fig:modelRulesUS2SP}
\end{figure}

Given the \textit{$\pi$-UseCase} model, to all {\sc Constraint} entity related
with a {\sc Use Case}, there is a {\sc Contract} that compounds a set of {\sc
Assertions} entity (figure \ref{fig:trans01}) and the {\sc Use Case} is refined
in a service {\sc Action}.  Considering the scenario example presented in Section
\ref{sec:example}, the transformation of the ``\textit{listen music}'' {\sc Use Case} are
transformed in a service {\sc Action}. This action is a Spotify service function
that can be invoked to play the music. For ``\textit{publish music}''
{\sc Use Case}, all {\sc Constrains} are transformed in a set of
{\sc Assertions} that are grouped in a {\sc Contract}
(``\textit{publishMusicContract}''). The
``\textit{publishMusicContract}'' is related with the ``\textit{publishMusic}''
{\sc Action}.


\begin{figure}[ht!]
\centering
\subfloat[From \textit{Extend} to \textit{Fork/Join Flow}]
{\label{fig:trans05}\includegraphics[width=0.9\textwidth]{chapters/implementation/figs/trans04}}
~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
\\
\subfloat[From \textit{Include} to \textit{Activity Node Flow}]
{\label{fig:trans06}\includegraphics[width=0.9\textwidth]{chapters/implementation/figs/trans05}}
~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
\caption{$\pi$-UseCase2$\pi$-ServiceProcess Model Transformation Rules (2)}
\label{fig:modelRulesUS2SP2}
\end{figure}

A {\sc Constrains} transformation means that from a {\sc Constraint} and {\sc
Constraint Type} entities are generated detailed {\sc Contract} information, that are refined in {\sc Exceptional
Behaviours} and {\sc Assertions} entities (figure \ref{fig:trans02}).
All {\sc Constraint} is related with a {\sc Constraint Type}, and there are
different cases for the transformation of this concept. A \textit{Business}
type are transformed in {\sc Assertion} that not considers the value attributes information, like \textit{maxValue} and \textit{minValue}
(see figure \ref{fig:usecasemodel}). These {\sc Assertion} information
attributes are considered if the {\sc Constraint Type} is a \textit{Value}
type. This transformation is semi-automatic, because there are not much
information in $\pi$-UseCase model to a complete automatic transformation. If
the {\sc Constraint Type} is a \textit{Value} type, the designer needs set the
variable information, and its boundary values after the transformation by the
tool. For this, the designer must consider the {\sc Constraint} and {\sc Use
Case} descriptions. By default, \textit{value constraints} are transformed into
\textit{pre-conditions} and  \textit{business constraints} are transformed into
\textit{post-conditions}. This rule may be adjusted by the designer at the time
of transformation.

A {\sc Service Activity} and the {\sc Actions} are generated from two different
element in the source model ($\pi$-UseCase), from a {\sc Requirement} or a {\sc
Composite Use Case}. Figures \ref{fig:trans03} and \ref{fig:trans04} present
the transformation schema for {\sc Requirement} and {\sc
Composite Use Case} concepts. Both elements are related with many {\sc Use
Cases} that are transformed in many {\sc Actions}. A {\sc Use Case} are related
with, either, a {\sc Requirement} and a {\sc Composite Use Case}. {\sc Actions}
are related with a {\sc Service Activity}. For example, the ``\textit{download
music}'' use case. For its execution is necessary process with the payment
process. Thus, the set of {\sc Use Cases} that include the ``\textit{download
music}'' process are transformed in {\sc Actions}, and a {\sc Service Activity}
that aggregates all these {\sc Actions} is also generated. 


\begin{figure} [ht!]
\centering

\subfloat[Extended Use Case Example]
{\label{fig:extend01}\includegraphics[width=0.3\textwidth]{chapters/implementation/figs/ucExtended}}
~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
\subfloat[Extended Use Case Example (2)]
{\label{fig:extend02}\includegraphics[width=0.3\textwidth]{chapters/implementation/figs/ucExtended2}}
\\
\subfloat[Equivalent Service Process Workflow]
{\label{fig:servProc01}\includegraphics[width=0.3\textwidth]{chapters/implementation/figs/servProc}}
~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
\subfloat[Equivalent Service Process Workflow (2)]
{\label{fig:servProc02}\includegraphics[width=0.3\textwidth]{chapters/implementation/figs/servProc2}}

\caption{Extended Transformation Examples}
\label{fig:modelRulesUS2SP}
\end{figure}


The transformation for {\sc Extend} and {\sc Include} elements is not as simple
as the previous transformation (figures \ref{fig:trans05} and
\ref{fig:trans06}). For each \textit{extends} relationship between two {\sc Use
Cases}, as shown in figure \ref{fig:extend01}, is generated one {\sc Fork Node},
one {\sc Join Node}, and four {\sc Control Flow} elements, and also two {\sc
Action} elements, one for each {\sc Use Case}, if there are less than 2 extended
{\sc Use Case} (figure \ref{fig:servProc01}). When there is more than one
extended use case, the transformation proceed at the same way, adding two more
{\sc Control Flow} for each new {\sc Use Case}, and one {\sc Action} for each
new extended {\sc Use Case}, as presented in figures \ref{fig:extend02} and
\ref{fig:servProc02}. Considering the scenario example, it is possible to apply
the same rule for the ``\textit{publish music}'' use case, which has two
extended use cases, ``\textit{public twitter}'' and ``\textit{public
Facebook}'', applying the illustration expressed in figures \ref{fig:extend02}
and \ref{fig:servProc02}.  

For {\sc Include} use case elements, the transformation is represented as a
{\sc Action} sequence, as shown in figure \ref{fig:trans06}. For each {\sc Use
Case} element is generated a {\sc Action} elements, and for ``\textit{n}'' {\sc
Use Cases} is generated ``\textit{n-1}'' {\sc Object Flow} elements. Each {\sc
Control Flow} to link two {\sc Action}. Given the ``\textit{download music}''
use case from the scenario example, it includes payment process to buy the
music. It is represented as a include in the $\pi$-UseCase model and is
transformed in a sequence flow in the $\pi$-ServiceProcess model.


All this transformation rules from \textit{$\pi$-UseCase} model to
\textit{$\pi$-ServiceProcess} model were validated with the scenario example.
All transformation described in this section are completely automatic, however
information about values, and its boundaries, are inserted by the designer after
the tool transformation process.


\subsection{From $\pi$-ServiceProcess to
$\pi$-ServiceComposition}

The transformation process from \textit{$\pi$-ServiceProcess} to
\textit{$\pi$-ServiceComposition} model will refine further more the application
design. The main goal of this transformation is group all {\sc Contracts} and
{\sc Actions} in {\sc Policies} and {\sc Service Activities}, respectively. 


For all {\sc Actions} entity in the source model will be transformed in a {\sc
Action} in the target model, and all {\sc Service Activity} in the source model
will be transformed in a {\sc Service Activity} in the target model. This
happens because \textit{$\pi$-ServiceComposition} is an extension of
\textit{$\pi$-ServiceProcess}.


For the non-functional specifications, the {\sc Contract} entity with the same
{\sc Non-Functional Requirement}, in the source model
(\textit{$\pi$-ServiceProcess} model), will be transformed in a {\sc Policy} in
the target model ($\pi$-ServiceComposition model).  Each {\sc Assertion} will be transformed in a
{\sc Rule:condition} attribute in the target model, but if the
{\sc Assertion} has the type equal to \textit{VALUE}, the \textit{name} and
the \textit{type} attribute in the source model will be transformed in a
\textbf{Variable} in the target model, and for the other {\sc Assertion
Property} value nothing happens.



The {\sc  Assertion:aProperty} attribute can have different transformations,
depending of the following values:

\begin{itemize}
\item \textit{POST-CONDITION} type is transformed into \textit{POST} in
the $\pi$-ServiceComposition model;
\item \textit{PRECONDITION} type is transformed into \textit{PRE}
in the $\pi$-ServiceComposition model;;
\item \textit{TIMERESTRICTION} type is transformed into \textit{TIME}
in the $\pi$-ServiceComposition model.
\end{itemize}

For the {\sc Exceptional Behavior} entity and its attributes, it will be
transformed in a {\sc Action} in the \textit{$\pi$-ServiceComposition} model,
and every {\sc Non-Functional Attribute} associated to an element
({\sc Contract} and {\sc Non-Functional Requirement}) in the
$\pi$-ServiceProcess model becomes a \textbf{Non-Functional Attribute} associated to the
corresponding element ({\sc Policy}) in the \textit{$\pi$-ServiceComposition}
model.

Table \ref{tab:transformationServiceProcessToComposition} describes the
transformations between \textit{$\pi$-ServiceProcess} and
\textit{$\pi$-ServiceComposition} meta-models.

\begin{table} [ht!]
\tiny
\renewcommand{\arraystretch}{1.3}
\caption{Transformation Rules: From $\pi$-ServiceProcess to
$\pi$-ServiceComposition}
\label{tab:transformationServiceProcessToComposition}
\centering
\begin{tabular}{l|l|l}
    \hline
    Source  &  Mapping Rules & Target\\
    $\pi$-ServiceProcess meta-model &   & $\pi$-ServiceComposition\\
      &&  meta-model\\
    \hline
    \hline

   Action & All \textbf{Actions} in the source model will be
   transformed in a \textbf{Action} in the target model. &Action\\
   \hline
   Service Activity&  - All \textbf{Service Activity} in the source model will
   be transformed in a \textbf{Service Activity} in the target model. &Service Activity,\\
   \hline
   Contract, & All \textbf{Contract} with the same \textbf{Non-Functional
   Requirement}, in the source model, will be transformed in& Policy\\
   Non-Functional Attribute&  a \textbf{Policy} in the target
   model.&\\
   \hline
   Assertion & Each \textbf{Assertion} will be transformed in a
   \textbf{Rule:condition} attribute in the target model. & Rule:condition\\
   \hline

   Assertion:name, & If the \textbf{Assertion} has the type equal to
   \textit{VALUE}, the \textit{name} and the \textit{type} attribute in the source
   model will & Variable\\
   Assertion:type & be transformed in a \textbf{Variable} in the target model.&
   \\
   \hline
   Exceptional Behavior & An \textbf{Exceptional Behavior} and its attributes in
   the source model will be transformed & Rule:action\\
   &in a \textbf{Rule:action} in the target model. &\\
   \hline
   Assertion:aProperty &- Depending on the \textbf{assertion Property} type in
   the source model, it will be transformed in a \textbf{Rule:event}&
   Rule:Event,\\ & in the target model. The transformation rules
    are:& Event Type\\
    &$\bullet$ \textit{PRECONDITION} type is transformed into \textit{PRE}
    in the target model;&\\
    &$\bullet$ \textit{POST-CONDITION} type is transformed into \textit{POST} in
    the target model;&\\
    &$\bullet$ \textit{TIMERESTRICTION} type is transformed into \textit{TIME}
    in the target model.&\\
   \hline

	Non-Functional & Every \textbf{Non-Functional Attribute} associated to an
	element (\textbf{Contract} and \textbf{Non-Functional} &
	Non-Functional \\ Attribute &  \textbf{Requirements}) in the source model
	becomes a \textbf{Non-Functional Attribute} associated to the  &
	Attribute \\
	&corresponding element (\textbf{Policy}) in the target model. &\\
	\hline
\end{tabular}
\end{table}




\begin{figure} [ht!]
  \centering
  \subfloat[From \textit{Contract} and \textit{Assertion} to \textit{Policy}
  and \textit{Rule}]
  {\label{fig:trans07}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans07}}
   %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
   \subfloat[From \textit{Action} to \textit{Service Activity} (2)]
  {\label{fig:trans08}\includegraphics[width=0.5\textwidth]{chapters/implementation/figs/trans08}}
  ~ %add desired spacing between images, e. g. ~, \quad, \qquad etc. (or a blank line to force the subfig onto a new line)
  \\
  \subfloat[From \textit{Exceptional Behaviour} to \textit{Action}]
  {\label{fig:trans09}\includegraphics[width=0.6\textwidth]{chapters/implementation/figs/trans09}}
  \caption{$\pi$-ServiceProcess2$\pi$-ServiceComposition Model Transformation
  Rules}
  \label{fig:modelRulesSp2SC}
\end{figure}


Figure \ref{fig:modelRulesSp2SC} presents the main transformation rules for
this level. From the goal of this work, the main feature of this
transformation level is the transformation of a set {\sc Contracts} in {\sc Policy}. But, \textit{what is
the adopted criterion for this transformation?} The main criteria is that all
{\sc Contracts} from the same {\sc Non-Functional Requirement} will be
transformed in {\sc Policy}. Thus, we can have {\sc Policies} on:
\textit{Safety, Performance, Reliability}, and so on.

A set of {\sc Assertions} are composed in one {\sc
Policy}, transformed directly into {\sc Rules}, and many {\sc Contracts} turn
into one {\sc Policy}. This happens because all {\sc Assertions} that represent
a contract, become directly in {\sc Rules}. Thus, the set of {\sc Rules} make up
a single {\sc Policy}. It is important to highlight that only the {\sc
Contracts} of the same {\sc Non-Functional Requirement} is transformed into the
same {\sc Policy}. Different NFRs' {\sc Contracts}, are transformed into
different {\sc Policies}. Figure \ref{fig:trans07} shows how this transformation
is made.

Similar to the transformation between {\sc Contract} and
{\sc Policy}, a set of {\sc Actions} is transformed into a single {\sc Service
Activity} entity. {\sc Actions} are related with {\sc Business Collaborator},
and all information related to a {\sc Business Collaborator} were transformed
from {\sc Packages} information ($\pi$-UseCase model). Thus, all {\sc Packages}
are transformed into {\sc Business Collaborator}. Figure \ref{fig:trans08}
presents the transformation between {\sc Action} and {\sc Service Activity}
elements.

An exceptional behavior is always related to a breach of a rule. If any {\sc
Rule} related with a {\sc Policy} is \textit{false}, an {\sc Exceptional Behavior}
must be performed to preserve the state of the application. Figure
\ref{fig:trans09} presents how an {\sc Exceptional Behaviour} that can be
transformed into an {\sc Action} call.

As the \textit{$\pi$-ServiceComposition} model refines the
\textit{$\pi$-ServiceProcess} concepts at PIM level, a service
previously defined as actions (source model) are refined as composition of
various actions (target model) that are necessary to represent a business
service, identifying who are the partners involved in the realization ({\sc
Business Collaborators}). In addition, $pi$SOD-M defines a platform specific
model based on web services composition. In this proposed model is explicitly
indicate those actions which are (or will be, if not yet implemented) supported
by web services. 

Considering the scenario example, the {\sc
Action}'s \textit{update music} {\sc Contract} is transformed is a {\sc Policy}
with its {\sc Rules}. All contract {\sc Assertions} are transformed in {\sc
Rule} and its attributes, \textit{e.g.} the login and password verification.  The
``\textit{securityLoginPolicy}'' is all set of {\sc Rules} that were transformed
from the {\sc Assertions} in $\pi$-ServiceProcess model. The {\sc Non-Functional
Requirement} information will be used to the {\sc Policy} generation comes from
the initial use case model. Also the {\sc Business Collaborator}
\textit{Facebook} and \textit{Spotify} information came from {\sc Package}
$\pi$-UseCase entity element. All {\sc Contracts} of the same {\sc
Non-Functional Requirement} are composed in a {\sc Policy}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%% FROM --> SERVICE COMPOSITION; TO PEWS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{From $\pi$-ServiceComposition to
$\pi$-PEWS}


Table \ref{tab:transformationServiceCompositionToPEWS} describes the
transformations between $\pi$-ServiceComposition and $\pi$-PEWS meta-models. There
are two groups of rules: those that transform services\' composition elements of the
$\pi$-ServiceComposition to $\pi$-PEWS meta-models elements; and those that
transform rules grouped by policies into A-policy types.

A named action of the $\pi$-ServiceComposition represented by  {\sc\em Action}
and {\sc\em Action:name} is transformed to a  named class {\sc Operation} with a
corresponding attribute name {\sc Operation:name}. A  named service activity
represented by the elements {\sc\em Service Activity}  and  {\sc\em
Service Activity:name} of the $\pi$-ServiceComposition, are  transformed into a
named operation of the $\pi$-{\sc Pews} represented by the elements  {\sc
Composite Operation} and {\sc Composite Operation:name}. When more than one action
is called, according to the following  composition patterns expressed using the
operators {\sc\em merge, decision, fork and join} in the $\pi$-ServiceComposition
the corresponding transformations, according to the PEWS operators presented
above, are:
\begin{itemize}
\item   $op_1 . op_2$ if no {\sc\em Control Node} is specified
\item ($op_1 \parallel op_2) . op_3$ if control nodes of type {\sc\em fork, join} are combined
\item ($op_1 + op_2) . op_3$ if control nodes of type {\sc\em decision, merge} are combined
\end{itemize}

The {\em A-policies} defined for the elements of the $\pi$-ServiceComposition are
transformed into {\sc A-Policy} classes, named according to the names expressed
in the source model. The transformation of the rules expressed in the
$\pi$-ServiceComposition is guided by the event types associated to these rules.
The variables associated to an {\em A-policy} expressed in the
$\pi$-ServiceComposition as {\sc\em $<$Variable:name, Variable:type$>$} are
transformed into elements of type {\sc Variable} with attributes {\sc name} and
{\sc type} directly specified from the elements {\sc\em  Variable:name} and
{\sc\em Variable:type} of the $\pi$-ServiceComposition model.


\begin{table}[ht!]
\tiny
\renewcommand{\arraystretch}{1.3}
\caption{Transformation Rules: From $\pi$-ServiceComposition to $\pi$-PEWS}
\label{tab:transformationServiceCompositionToPEWS}
\centering
\begin{tabular}{l|l|l}
    \hline
    Source  &  Mapping Rules & Target\\
    $\pi$-ServiceComposition meta-model  &   & $\pi$-PEWS meta-model\\
    \hline
    \hline

    Action   &  - An \textit{Action} in the source model corresponding to an
    external \textbf{Business Collaborator} is mapped  & Operation:alias\\
       &   to an Operation in target model.   & \\
       &   - The \textbf{Action:name} in the source model is transformed into
       \textbf{Operation:name} in the target model.  & \\
    \hline

    Service Activity    & - The \textbf{Service Activity} in the source model is
    mapped to a \textbf{Composite Operation} in target  & Type Operation,\\
        &  model when more than one \textbf{Actions} are called.   &
        Composition Operation\\

        & - If \textbf{Composite Operation} is generated for a given
        \textit{Service Activity} then the \textbf{Service Activity:name} & \\
        & in the source model is mapped to
        \textbf{Composition Operation:name} in the target model. &\\
    \hline

    Control Nodes   &  - The \textbf{Control Node} in the source model is mapped
    to a \textbf{Operator} in target model. According to the & Operator\\

    & type of \textbf{Control Node} (merge, decision, join, fork)
    the expression of the \textbf{Composite Operation} is: & \\

    &  $\bullet$ Sequence if no \textbf{Control Node} is specified;  & \\
    &  $\bullet$ Parallel - Sequence for  a \textbf{Control Nodes} pattern fork -
    join; & \\ &
    $\bullet$ Choice - Sequence for a \textbf{Control Node} pattern decision -
    merge &
    \\

    \hline

    Business Collaborator   & A \textbf{Business Collaborator:isExternal} in the
    source model generates a \textbf{Namespaces} in the target model  &
    Namespace\\
    \hline

    Rule:event   &  The \textbf{Rule}\'s attribute event in the source model is
    transformed into an \textbf{Event:type} of the target  & Event Type,\\
    & model. In this case attribute is mapped to an
entity with an attribute. The \textbf{Event Type} of a & Event\\
  & \textbf{Rule} in the target model is
determined by the Rule type: & \\
     &  $\bullet$ \textbf{Event Type} of a \textit{Precondition} \textbf{Rule} is
     \textit{ActivityPrepared}; & \\
     &  $\bullet$ \textbf{Event Type} of a \textit{Postcondition} \textbf{Rule}
     is \textit{TermActivity}; & \\
    &  $\bullet$ \textbf{Event Type} of a \textit{TimeRestriction} \textbf{Rule}
     is \textit{Activity}; & \\
    \hline

    Rule:condition   &  The \textbf{Rule}\'s attribute condition in the source
    model is transformed into a \textbf{Condition:expression}  & Condition\\
    &  in the target model.  In this case, an attribute is
mapped into an entity with an attribute  & \\
    \hline

    Rule:action   & The \textbf{Rule:action} in the source model is
    transformed in an \textbf{Action:act} in the target model.  & Action\\
    & The attribute action is mapped to an entity with an attribute. In the
    target model an action & \\
    & is executed according to the rule condition value (true/false). & \\

    \hline

    Policy   & - Every \textbf{Policy} associated to an element
    (\textbf{Business Collaborator, Service, Activity, Action}) in the   &
    APolicy\\
    & source model becomes an \textbf{APolicy} associated to the corresponding
element in the target model. & \\
   & - The name attribute of a \textbf{Policy} in the source model becomes an
\textbf{Apolicy:name} of the target model. & \\
    \hline
    Variable   &  Every \textbf{Variable}, and its attributes, associated to a
    \textbf{Policy} in the source model
    becomes a \textbf{Variable}   & Variable\\
    &associated to an \textbf{APolicy} in the target
    model. The variables can be used in an \textbf{APolicy}\'s Condition &\\
    & of the target model.&\\
    \hline
    Rule:event &  For a \textbf{Rule} in the source
    model, depending on the \textbf{Event Type}, the corresponding transformation
    & Precondition \\ &   in the target model is: \textbf{Precondition,
    Postcondition} or \textbf{TimeRestriction Rule}  & Postcondition\\
    &&TimeRestriction\\
    &&Rule\\
    \hline
\end{tabular}
\end{table}

As shown in Table \ref{tab:transformationServiceCompositionToPEWS}, for an event
of type {\sc\em Pre} the corresponding transformed rule is of type {\sc
Precondition}; for an event of type {\sc\em Post} the corresponding transformed
rule is of type {\sc Post-condition}; finally, for an event of type {\sc\em
TimeRestriction} the corresponding transformed rule is of type {\sc Time}. The
condition expression of a rule in the $\pi$-ServiceComposition ({\sc\em
Rule:condition}) is transformed into a class {\sc\em Condition:expression} where
the attributes of the expression are transformed into elements of type {\sc
Attribute}.



\section{Conclusions}
\label{sec:pisodm_conclusion}


This chapter presented $\pi$-SOD-M for specifying and designing reliable service
based applications. We model and associate policies to  services' based
applications that represent both systems' cross-cutting aspects and use
constraints stemming from the services used for implementing them. We extended
the SOD-M method, particularly the $\pi$-UseCase meta-model,
$\pi$-ServiceProcess meta-model, $\pi$-ServiceComposition meta-model and we
defined $\pi$-PEWS meta-models for representing both the  application logic
and its associated non-functional constraints and then generating its executable code.


Non-functional constraints are related to business rules associated to the
general "semantics" of the application and in the case of services' based
applications, they also concern the use constraints imposed by the services. We
worked on the definition of a method for explicitly expressing
such properties in the early stages of the specification of services based
applications. Having such business rules expressed and then translated and
associated to the services' composition can help to ensure that the resulting
application is compliant to the user requirements and also to the
characteristics of the services it uses.


Designing and programming non-functional properties is not an easy task, so we
are defining a set of predefined {\em Policy} types with the associated use rules for guiding
the programmer when she associates them to a concrete application. {\em Policy}
type  that can also serve as patterns for programming or specializing the way
non-functional constraints are programmed.

An advantage of our methodology is the use of high-level models,
not just use case models, which, by means of model transformations, helps
software developers to make the most of the knowledge for specifying and
developing business services. Before entering in detail in the models and the
proposed process by $\pi$SOD-M, in the next section presents the methodology in
the context of MDA architecture, which supports the proposed method.



